home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000114-20000217
/
000030_news@columbia.edu _Mon Jan 17 10:55:49 2000.msg
< prev
next >
Wrap
Text File
|
2000-02-16
|
6KB
|
120 lines
Article 10955 of comp.protocols.kermit.misc:
Path: newsmaster.cc.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MS-DOS Kermit, more capabalities
Date: 17 Jan 2000 16:04:14 GMT
Organization: Columbia University
Lines: 103
Message-ID: <85vehu$55p$1@newsmaster.cc.columbia.edu>
References: <011700040222not-2-disclose@the.net>
NNTP-Posting-Host: watsun.cc.columbia.edu
X-Trace: newsmaster.cc.columbia.edu 948125054 5305 128.59.39.2 (17 Jan 2000 16:04:14 GMT)
X-Complaints-To: postmaster@columbia.edu
NNTP-Posting-Date: 17 Jan 2000 16:04:14 GMT
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:10955
In article <011700040222not-2-disclose@the.net>,
<not-2-disclose@the.net> wrote:
: ...
: In the past two weeks or so, i couldn't but take note that MY NEED for
: a `ZMoDem' protocol has been disregarded from the start; ...
:
Again, this is the Kermit Project, not the Zmodem Project. The source
for Zmodem is Omen Technogy. If you want Zmodem software for DOS, you
can get it from there.
If you want Zmodem software with Kermit scripting for DOS, you're in the
unenviable position of having to put it together yourself. It's not
Omen's job to give you Kermit scripting, and it's not our job to give you
Zmodem protocol.
: it's been suggested that a guy just has to ask for help when he needs it
:
Within reason. We support our software for what it was designed to do.
: and i'm surprized since it happens that's exactly what i tried to do but
: no one cared to point at a clear solution for MY MACRO PROBLEM...
:
There are real people at work here. For some of us, it is our job. For
others, all participation is voluntary, outside of their real jobs. The
demands on our time are greater than the time available. We do our best
to serve the largest number of people in the time we have.
If you have bug reports, we welcome them. If you have questions of
reasonable scope, we try to answer them. If you have suggestions,
we'll listen to them, but we're not obligated to act on them. If we
have a hundred thousand users anxiously waiting for some particular new
feature in one of our programs, and one person looking for some other
feature, all else being equal, I think the course is clear.
I think most readers of and contributors to this newsgroup enjoy a good
discussion, but if you're trying to accomplish a change in the status
quo, it is usually more effective to:
. Be concise -- nobody has time to read a 500-line posting.
. Reduce problems to the minimum scenario needed to reproduce them.
Nobody is going to wade through a long script hunting for where
the problem might be.
. Keep your postings focused. If you have several topics, make a
separate posting for each one.
. Try to maintain a good-humored and civil tone.
Your complaint about BBS's not supporting a good, or even functional,
Kermit implementation is a familiar one. We have no power over makers
of BBS software, or over BBS Sysops. And if you think about it, you
can also understand why we might not have much sympathy for a company
that sells a product that includes a substandard or nonfunction Kermit
implementation -- they get the money, we get the complaints.
Nevertheless, we have been doing our best to show the BBS world how
they can improve the situation. Read, for example, the article on
MS-DOS Kermit and BBS's here:
http://www.columbia.edu/kermit/newsn6.html#bbs
It's as true now as it was when it was written nearly 5 years ago.
Send a copy to the Sysops of the BBS's that you use and ask them to
follow the directions, and then your troubles are over.
: I also have trouble with some kind of "memory
: low" error - AFTER *SUCCESSIVE ACTUATIONS* of the READING macro...
: More precisely, i get a "TOO MANY ACTIVE TAKE FILES AND MACROS" message...
:
MS-DOS Kermit and the environment it runs in have memory limitations.
Now, I'm all for the idea of keeping old equipment alive and finding new
uses for it, but when you consider that you can buy an Internet ready
PC with 32 or 64MB of memory today for a fraction of the cost of the
original IBM PC, maybe it's time to look at how much your time is worth.
Kermit 95, which you can run on Windows 95 and higher, is a "large memory
model" version of Kermit that has few noticeable limitations in scripting.
It is a better platform for long and complicated scripts because it has
more capacity for them, because the underlying hardware and OS support
bigger things.
; i'm
: starting to suspect that i must be terminating my macros incorrectly but
: i fail to see how and now i need a precise, tested, WORKING hint. Would
: somebody be kind enough to RUN THE FOLLOWING SET OF MACROS and then tell
: me what i'm doing wrong??? So far, I ALREADY KNOW that some characters
: pose a problem when found at the end of the line; "dash" is one... The
: OBVIOUS TEMPORARY remedy is not to use a hyphen at the end of a line but
: that's not satisfying at all, really!... Moreover, other characters are
: "forbiden", i'd like to be able to do simple UNFILTERED ~ASCII~ UpLoads!
:
Here are a couple observations that might be helpful:
1. Dash (hyphen) is the continuation character for commands. It should
have no effect when it appears on the end of a line in a data file,
such as a line obtained with the READ command. However, there might
be a bug in MS-DOS Kermit in this area. We will look into it.
2. The command to use for ASCII uploads is TRANSMIT. If you use that
instead of OPEN READ, READ, ..., CLOSE READ, you won't experience
any interference with the data.
- Frank